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(g) Access control in a distributed computer system. 

(g?) A distributed computer system, has a number of users and target applications. When a user logs on to 
the system, an authentication unit issues the user with a privilege attribute certfficate (PAC) represent- 
ing the user's access rights. When the user wishes to access a target application, he presents the PAC to 
that application as evidence of his access rights. The application, In turn, passes the PAC to a PAC use 
monitor (PUM) which validates the PAC. The PUM is shared between a plurality of applications. 
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Background to the Invention 

This invention relates to a method and apparatus for controlling access by users to applications programs 

Manufacturers' Association (ECMA) and is described in the following references. 

1) ECMA TR/46 "Security In Open Systems - a Security Framework" July 1988 

2) ECMA standard ECMA/138 December 1989 

3) "Network Access Control Development". COM P ACS 90 Conference, London. March 1990 

The ECMA security framework permits a user to be authenticated to the system, and to obtam as a result 
a data package referred to as a privilege attribute certificate (PAC) which represents a certified collection of 
access rightTwhen the user wishes to access a target application, the user presents the PAC to that application 
as evidence of the user's access rights. . 

An advantage of this approach is that the user does not need to be authenticated separately to individual 
■wjSSTSi authenftSon procedure is performed once only, to obtain the PAC. The PAC can then be 
used several times to access different applications. 

ThVottfect of the present Invention is to build on this idea of using PACs. to provide an Improved method 

of access control. 
Summary of the Invention 

According to the invention there is provided a distributed computer system capable of supporting a plurality 
of users and a plurality of applications, the system including an authentication unit for authenticate a user 
tSSS H userwtth a pLege attribute certificate (PAC) which can then be presented to anj appl Icabon 
Z EES as evidence of S» user's access rights, characterised by a validation unit, common to a pUaaMy 
of applications, forvalkJating PACs received by those applications to determine whether the users that presen- 
ted those PACs are permitted to access those applications. 

Brief Description of the Drawings 

Fiaure 1 1s a schematic diagram of a distributed computer system embodying the invention. - 
Ffcure 2 is a sequence diagram showing the steps In the protocol for connecting a user to a target appll- 

cation. * l j_ 

Figure 3 Is a sequence diagram showing the protocol for revoking access rights. 

Figure 4 shows a modification of the protocol. 
Description of an Embodiment of the Invention 

One distributed computer system embodying the invention will now be described by way of example with 
reference to the accompanying drawings. . r 

Referring to Figure 1 . the system comprises a numberof target applications 10. Forexample. a target appli- 
cation mav be a database program, or an electronic mail program. 

Human users Interface with the system by way ofusersponsors11.Each user^or^r isasoftw^modute 
which acts as the representative for a user in all activities within the system. In particular, rt represents the user 
in establishing the user's rights to access the target applications. , 

The user sponsors 11 communicate with an authentication and privilege attribute server (APA server) 1 2. 
which provides an authentication service for the system. The APA server provides each authenticated user wtth 
Iprmlege attribute certificate (PAC) representing the user's access rights within the system. The user sponsor 
oa^menuse the PACtoaccess the target applications. The tergetapplkattonsthemsetyesm^ require to 
form accesses to further applications on behalf of the user. To authorise these accesses, they may need to 
pass orMhe^ser's PAC, as If they themselves were user sponsors. As will be described, the ability of a target 
application to re-use a PAC is controlled, to prevent insecure applications from using PACs in an pr0 ' )8 p!"Jf^ 

The system also includes at least one PAC Use Monitor (PUM) 13. In this exarnple. *ere ™^ 
in the system: The PUMs provide a service to the target applications by validating the PACs when requested, 
so as to determine whether a particular user has the right to access a particular target application 

Where there are several PUMs In the system they may be divided into a number of groups, according to 
the degree of trustworthiness of the PUM. For example, the PUMs may be divided I into two flroup« a tousted 
group and a less trusted group. As will be described, the user may then specify which group of PUMs he wishes 
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to validate a particular PAC, according to the degree of security required by the user for that PAC. 

The protocol for connecting a user to a target application will now be described with reference to Figure 2. 
The numbering of the steps below corresponds to the numbering of the data exchanges shown in that figure. 

In the drawing, square ,bmd^^arej(£g^ int^rity sealing, for Prayjgtafl 

5 detection. Round brackets denote encryption ^ 

data is both sealed and encrypted. In each case the encryption key is indicated by a subscript For example. 

{PAC}kap 

indicates that PAC is sealed and encrypted under the key KAP. 

1) The user logs on to the APA server via his user sponsor. This may involve a conventional log-on pro- 
10 cedure which will not be described herein. This procedure generates a cryptographic key KUA, unique to 

the user, which is used for subsequent exchanges between the user sponsor and the APA server. 

2) The user sponsor requests a PAC. The user may specify, by means of a group identifier KGID, the group 
of PUMs by which the PAC is required to be validated. The user may also specify, by means of an indicator 
flag AA-IND, whether he requires the target application for which this PAC is to be used to be authenticated. 

15 The request, KGID, and AA-IND are all encrypted under the key KUA. 

3) When the APA server receives the PAC request, it checks the user's access rights. These depend on 
the user's status In the system (e.g. his job In the organisation, his security clearance, etc). The APA server 
then returns to the user sponsor, under the protection of the key KUA, a package of Information containing 
the following: 

20 AID: The identity of the ASA server 

KVN: The version number of the key KAP (see below) 

KUT: A pseudo-randomly generated key for use in communication between the user sponsor and 

the target application 

KUP: A pseudo-randomly generated key for use in communications between the user sponsor and 

25 the PUM 

{PACK*** A copy of the privilege attribute certificate (PAC), representing the user's access rights as 
determined by the APA server. This is sealed and encrypted under RAP, a predetermined 
key which is known to the APA server and to the PUMs in the group specified by KGID. All 
the PDMs in the same group share the same key KAP, while different groups have different 
30 keys KAP. 

PAT: Attribute data extracted from the privilege attribute certificate. 

The contents of the PAC are as follows: 

Attn The access privHege attributes of the user 

PAC-tgt-Qual: Constraints imposed by the ASA server on target applications for which the PAC is valid 
35 KUT: A copy of the key KUT 

KUP: A copy of the key KUP 

PAC-Expiry: The expiry time of the PAC 

4) The user may now select a target application he wishes to access. The user sponsor connects to this 
application and passes to it AID, KVN, KGID, and the sealed and encrypted PAC, as obtained from the 

40 ASA server. The user sponsor also creates a qualifier token Quals for the PAC, and passes this to the target 
application, under protection of the key KUP. Quals contain one or more PAC Qualifiers, each containing 
the following information: 

PACID; The unique identity of the PAC to which the qualifier relates 

Tgt-Qual: Constraints on the permissible applications) for which the PAC is valid for use with this qual- 
45 ifier. These constraints may be a subset of those that appear in the PAC itself 

Attr-Qual: The subset of privilege attributes which are to be valid from this PAC for use with this qualifier. 

Note that the PAC may contain attributes which constrain the minimum as well as the 
maximum bounds for this choice. 
Q-Expky: Expiry information determining the time window within which the PAC must be validated with 
co this qualifier. 

QID: An identifier for this qualifier. 

Count The number of times this qualifier may be submitted for successful validation of its PAC 

5) The target application now identifies which PUM it is required to use to validate the PAC, as specified 
by the value of KGID (if any) supplied by the user sponsor. The target application passes to this PUM all 

as the information just received from the user sponsor, together with an indication T1D of the identity of the 

target application. 

When the PUM receives this Information, it performs the following actions. 

Fk-st the PUM examines the target application identity TID, and determines whether or not it is willing to 
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validate a PAC from this particular application. . for , „ 

Assuming that the PUM is willing to validate this PAC, it now uses the values of AID and KVN to determine 
which kev KAP to use. It then uses this key to decrypt and integrity check the PAC. 

^KTp^L uses the key KUP (obtained from the decrypted PAC) to . 
5 qualifier token Quals;^'ineWti^ * one or more qualified ifie P Jrtpesfarins ^l- ■ 

lowina actions in respect of each of these qualifiers in turn. 
-Ch^* 

and start again on the next one. 

_ Cneck the Qualifier has not already been used the maximum permitted number of times. If it has, 
io ignore this Qualifier and start again on the next one. 

For the purpose of this check, the combination of PACID and QID is used to index a count table containing 
a count of the number of times each such combination has been validated. If there Is no existing entry, then 
an entry is created and set to 1 to indicate that this is the first time. Otherwise the contents of the entry are 
incremented and compared with tbe permitted maximum value count (obtained from the Qualifier). If the result 
exceeds the Qualifier count then the Qualifier is already used up. 

- Check that Tgt-Qual in the Qualifier matches the attributes of the target application in question, as Iden- 
tified by the TID. If this feBs, abandon checking and return a validation failure. 

_ CheJfc vaius ?n Q-Expiry to ensure that ths Qualifier has not expired. If this fails, abandon cnocklng 
and return a validation failure. 

If all of the checks succeed then validation is successful for the Qualifier being checked. 

6) The PUM returns the following information: KUT: 

If validation succeeded, the key that the application is to use with the user sponsor. 
Val-Attnr If validation succeeded, the privilege attributes that the user possesses for this use of the 
target application, along with any other control information that may be in the PAC and the 
application may need to know (such as audit information). 
OK/Ern Indication of the success or otherwise of the validation. This, together with Chk-Data des- 
cribed below is sealed under KUP. . 
Chk-Data: Data which gives details of the validation that has been undertaken. It contains the following 

information: 

i) PACID, the identity of the checked PAC 
if) TID, the attributes claimed by the application 
in) T-Checked, the time at which the PAC was validated 

iv) The QID of the qualifier used 

v) Auth-Ind, which indicates whether the application's claimed TID was authenticated. - 
vn C-Rem, the count value remaining unused for this Qualifier. 

7) The target application replies to the user sponsor with the sealed success or feBure indication from the 
PUM together with the Chk-Data, both protected under KUT. 

8) The user sponsor may now start performing operations and obtaining responses from the target appli- 
cation under the protection of KUT. 

Referring now to Figure 3, this shows the way in which the APA server can revoke a PAC. 
The APA server sends a Revoke-PAC message directly to each PUM in the system, the message conta n- 
inq the identity PACID of the PAC to be revoked. The revocation may be qualified by specifying Jhe particular 
targets for which the PAC is to be revoked, and the time from which the revocation is to be effective. 
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It can be seen that the access control technique described above does not require the use of any asym- 
metric cryptographic functions, it requires each target application to access a PUM to arbitrate on the validity 
of a PAC The PUM can be very simple and fast, and contains no long-term data except a cryptographic key 
so and the names (and possibly attributes) of the applications it is wDling to service. The PUMs therefore require 
minimal management, and the provision of a plurality of PUMs does not present any consistency f^blerns. A 
particular PUM can be cc-located with Its client applications. Alternatively, a PUM for use by applications run- 
ning on a relatively insecure system can be provided at a separate and more secure location. 

Moreover, the sshystem provides for Immediate PAC revocation since the APA server can contact each 
55 pi|M directly to revoke a specified PAC. 

The parameter TGt-Qual in the qualifier permits a user to specify for which target applications the PAC is 
to be valid. The user's choice can be constrained by the APA server. „ A/% «_ w^..«^ 

Moreover, the parameters QID and Count in the qualifiers allow the user to prevent a PAC from being used 
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with a particular Qualifier more than a nominated number of times. This enables the user to restrict further use 
of the PAC by the target application. In particular, if the user specifies that the PAC Is to be used only once, 
then It Es not possible for the target application to re-use the PAC to access other applications. Furthermore, 
the parameter Q-expiry in the qualifier allows the user sponsor to impose a time span, shorter thanJthe_PAC 
- -"^ ^ tErgetVp^^il6"n?th^ c&ota P&Ct with life spans^u^?^^-: - 

long as the whole user session to be issued safely by the APA server, while allowing the user sponsor to limit 
use of the PAC by the target application. 

The system requires no long-term storage of cryptographic keys in the user sponsor. Moreover, it ensures 
that the user sponsor that was issued the PAC is the one which subsequently controls its repeated use. 
10 The only cryptographic keys in the system that have to be stored on a long-term basis are the keys KAP. 

The others are all generated dynamically when required. 

Some Possible Modifications 

15 It wBI be appreciated that many modifications can be made to the system described above without departing 

from the scope of the present invention. 

For example, cryptographic protection may be provided over the links between the target applications and 
the PUM. Alternatively, the c^ptog 

or more of the target applications may be removed. This avoids the need for any cryptographic functionality in 

20 those target applications. 

A number of national governments will permit for general use only those cryptographic schemes in which 
the uses of encryption to hide data are minimised. This in practice requires that only cryptographic keys may 
be transmitted in encrypted form. The variation shown in Figure 4 is an adaptation of the system intended to 
satisfy these government requirements. 
26 The variation introduces a PAC Token (P7) which now carries the confidential information that in the pre- 

viously described scheme was carried in the PAC. The PT consists of the keys KUP and KUT, linked to the 
PAC by means of PACID, and is encrypted under the key KAP. The PAC token PT is the only information trans- 
mitted In encrypted form. Other information is cryptographically sealed, as indicated by the square brackets, 
to provide tamper detection without being encrypted. The adapted protocol is otherwise serf-explanatory in the 
so Figure. 



Claims 

35 1. A distributed computer system capable of supporting a plurality of users and a plurality of applications (1 0), 
the system including an authentication unit (12) for authenticating a user and issuing that user with a 
privilege attribute certificate (PAC) which can then be presented to an application by the user as evidence 
of the user's access rights, characterised by a validation unit (13), common to a plurality of applications 
(10), for validating PACs received by those applications to determine whether the users that presented 

40 those PACs are permitted to access those applications. 

2. A system according to claim 1 in which the user can dynamically control the access rights the user wishes 
to be active with respect to chosen applications, without further accesses to the authentication unit 

46 3. A system according to claim 2 wherein the user passes the PAC to an application along with a PAC qualifier, 
specifying the access rights that the user wishes to be active for that application. 

4. A system according to claim 3 wherein the PAC qualifier contains a count value specifying the maximum 
number of times the PAC may be presented for validation with this qualifier. 

50 

'& A system according to any preceding claim in which the authentication unit can directly access the vali- 
dation unit to revoke a specified PAC. 

6. A system according to any preceding claim wherein the PAC is cryptographically protected between the 
55 authentication unit and the validation unit 

7. A system according to any preceding claim wherein each PAC contains a cryptographic key for use in com- 
munication between the user and the application, and wherein, when the validation unit validates a PAC 
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on 



behalf of a particular application, it passes that cryptographic key to the application. 



8. A system according to claim 1 wherein the user can request that the application the user is to access be 

authenticated, and to be securely i^ been achieved. v „ „ , .. ..... _ . ; 
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Fig.2. 
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